Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / networking / terms / kermit / e / v11.1 < prev next >

Wrap

Internet Message Format | 1990-01-04 | 20.7 KB

From cmg Thu Jan 4 18:25:07 1990 Return-Path: <cmg> Received: by watsun.cc.columbia.edu (5.59/FCB) id AA03603; Thu, 4 Jan 90 18:25:07 EST Date: Thu, 4 Jan 90 18:25:06 EST From: Christine M Gianone <cmg@watsun.cc.columbia.edu> To: info-kermit Subject: Info-Kermit Digest V11 #1 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Message-Id: <CMM.0.88.631495506.cmg@watsun.cc.columbia.edu> Info-Kermit Digest Thu, 4 Jan 1990 Volume 11 : Number 1 PROPOSALS FOR KERMIT PROTOCOL ADDITIONS - Proposal for Kermit SET FILE COLLISION Command Proposal for Kermit SET ATTRIBUTE Command Proposal for REMOTE SET Extension to the Kermit Protocol Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU, requests for addition to or deletion from the Info-Kermit subscriber list to Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU or to KERMIT@CUVMA.BITNET. Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN, WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.0), IP host number 128.59,39.2. 128.59.40.130. Login as user anonymous (note, lower case), any password, and GET or MGET the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. You can also get Kermit files over BITNET/EARN; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Mon, 11 Dec 89 19:15:07 EST >From: Christine M Gianone <cmg@watsun.cc.columbia.edu> Subject: Kermit Protocol Additions Keywords: Kermit Protocol This issue of the Info-Kermit Digest contains several proposals for extending the Kermit protocol in certain minor ways, all of them related. These discussions are for Kermit developers. They assume familiarity with the Kermit protocol, as described in "Kermit, A File Transfer Protocol", by Frank da Cruz, Digital Press (1987). ------------------------------ Date: Mon, 11 Dec 89 19:15:07 EST >From: Christine M Gianone <cmg@watsun.cc.columbia.edu> Subject: Proposal for Kermit SET FILE COLLISION Command Keywords: Kermit Protocol, SET FILE Command PROBLEM: As pointed out by Gregg Wonderly in Info-Kermit V10 #4, as well as by John Chandler (author of Kermit-370) and many others previously, Kermit's SET WARNING (sometimes also known as SET FILE WARNING) command is misnamed and furthermore does not allow for certain desirable kinds of behavior when a file arrives which has the same name as an existing file. SOLUTION: A new command to replace the old SET [FILE] WARNING command (or which can coexist with it): SET FILE COLLISION, similar to the SET FILE EXISTS command which was proposed by Gregg. The name was changed for grammar's sake, several additional options are suggested, and their behavior described somewhat differently: SET FILE COLLISION REPLACE: Destroy the previously existing file, replace it with the new copy (the current behavior of SET WARNING OFF). SET FILE COLLISION RENAME: Give the incoming file a new, unique name so that it won't overwrite any existing files (like SET WARNING ON). This would be the default behavior. SET FILE COLLISION BACKUP: Give the existing file a new, unique name, using the same algorithm that is used on the arriving file by SET FILE COLLISION RENAME, and then accept the incoming file under its own name. SET FILE COLLISION DISCARD: Reject any incoming file that has the same name as an existing file using (a) the attribute refusal mechanism ("N" in the data field of the ACK to the Attribute packet) if the use of attribute packets was negotiated, (b) by putting an "X" in the data field of acknowledgements to any Data packets that arrive to request cancellation of the file. Always use method (b), even if also using method (a), in order to get on to the next file as quickly as possible. In case the sending Kermit does not understand either of these signals and the file continues to arrive, do not open a new file and simply acknowledge and discard all data packets up to the end of the file. As Gregg pointed out, the DISCARD option will be handy for resuming transfer of a file group that had been interrupted. This gives us a cheap version of checkpointing. A more general and protocol-driven checkpointing mechanism will be proposed in the future. SET FILE COLLISION APPEND: Append an arriving file to an existing file that has the same name. The resulting file keeps the same system-dependent characteristics it had before, except that the date is changed. This option should be used with caution, since it opens the door to creating files of mixed types (e.g. a text file appended to a binary file, a spreadsheet appeneded to a database, etc). Old versions of IBM mainframe Kermit operated in this way. SET FILE COLLISION ASK: Ask the user whether to replace, rename, discard, or append each arriving file that has the same name as an existing file. This option, too, should be used with caution because the file transfer could time out if the user takes too long to answer the query. There are also user-interface issues: what happens to the active file transfer display, etc. Macintosh Kermit currently supports this in the form of of "attended file transfer mode". When the REPLACE and BACKUP options are in effect, a question arises (originally posed by John Chandler). Should the receiving Kermit create the new file using its current file settings (SET FILE TYPE, etc), or should the new file inherit the characteristics of the existing file, like protection, blocksize, record format, etc, on systems where files have such things (IBM mainframes, VAX/VMS, etc)? There should also be a command to let the user specify this: SET FILE REPLACE {PRESERVE, DEFAULT} where PRESERVE would create the new file with the same characteristics as the old one, and DEFAULT would use the current file settings of the receiving Kermit program and the host operating system when creating the new file. The setting of SET FILE COLLISION will have an effect (as FILE WARNING does now) upon the receiving Kermit's handling of the file size attribute as reported in the incoming Attribute packet. If the REPLACE option is in force, then the existing file's size must be added to the available space before deciding whether to accept or refuse the file on the basis of space. This new command involves no new protocol. Its operation is strictly local to the receiving Kermit program, and gives the user added control over its behavior when receiving files. ------------------------------ Date: Mon, 11 Dec 89 19:15:07 EST >From: Christine M Gianone <cmg@watsun.cc.columbia.edu> Subject: Proposal for Kermit SET ATTRIBUTE Command Keywords: Kermit Protocol, SET ATTRIBUTE Command PROBLEM: As the use of File Attribute (A) packets within Kermit programs grows more widespread, it is becoming apparent that the user needs to have more control over this feature. Currently, most Kermit programs that support attribute packets have a command SET ATTRIBUTES {ON, OFF}, so that if one or more attributes is causing problems on the receiving computer, the sender can be commanded not to send any attributes at all and the receiver can be told to ignore all incoming attributes. For example, suppose both the sender and receiver programs support the file creation date attribute, and the receiver sets the arriving file's date from it. On some computers, incremental backups work according the file date and so files that are received by Kermit won't be backed up. If the user gives the SET ATTRIBUTES OFF command, then the current date will be used when creating the incoming file, but other useful attributes like file size will be absent or ignored. In this case, the receiving Kermit will not be able to reject an arriving file in advance if it would be too big to fit on the available storage. You should not have to sacrifice all file attributes if only one of them is causing problems. Furthermore, it is possible to imagine situations in which you want a certain attribute to be effective when sending a file but not when receiving, or vice-versa. For example, suppose the date attribute works correctly when receiving a file, but when sending a file it causes the other Kermit program to crash because of a bug. In this case, you need a way of telling your Kermit program to not to send the date attribute, but still continue to handle for incoming files. SOLUTION: A new command, SET ATTRIBUTE <name> {IN, OUT} {ON, OFF}. The <name> is the name of any Kermit attribute as listed on pp.272-279 of the Kermit book, or else the word ALL to mean all attributes. IN OFF means that the attribute should be ignored if it appears in an incoming File Attribute packet. OUT OFF means that the named attribute should not be included in any File Attribute packets which are sent. IN ON and OUT ON are used to enable the named incoming or outbound attributes. If you specify ALL OFF, then the Kermit program should not set Attribute bit in the capabilities field of its Send-Init packet (equivalent to the current command SET ATTRIBUTES OFF). Examples: Command Meaning SET ATTRIBUTE LENGTH IN OFF Ignore incoming length attributes SET ATTRIBUTE DATE OUT OFF Omit date from outbound attributes SET ATTRIBUTE DATE OUT ON Include date from outbound attributes SET ATTRIBUTE ALL OUT OFF Don't send any attributes SET ATTRIBUTE ALL IN OFF Ignore all incoming attributes This new command is completely self-contained within each Kermit program. There is no additional protocol between the two Kermit programs. Thanks to John Chandler and Joe Doupnik for advice and suggestions on these new commands. ------------------------------ Date: Mon, 11 Dec 89 19:15:07 EST >From: Christine M Gianone <cmg@watsun.cc.columbia.edu> Subject: Proposal for REMOTE SET Extension to the Kermit Protocol Keywords: Kermit Protocol, REMOTE SET Command PROBLEM: Certain Kermit programs (including MS-Kermit 3.0, C-Kermit 4F) include information about whether a file is text or binary in the File Attribute packet, so the receiver can put itself into the right mode automatically. But when talking to a server there is no way for the client program, before issuing a GET command, to tell the server whether to send the file in text or binary mode. This problem extends to various other protocol and file-related parameters. NOTE: The Kermit protocol definition includes a REMOTE KERMIT command, and the associated packet format and protocol. It lets the user of the client program issue a command to the server in its own interactive-mode command language. But this is not a totally satisfactory answer because the syntax of Kermit programs can and does vary and, perhaps more to the point, some Kermit programs do not have an interactive command mode at all (Macintosh Kermit is one example). What is needed is a standard mechanism and syntax that can apply to all Kermit programs uniformly. SOLUTION: A new addition to the Kermit protocol: REMOTE SET. REMOTE SET would be a Generic Kermit Server command. A generic command looks like this: +-----+---------------------------------+ | G | x <len1> <op1> <len2> <op2> ... | +-----+---------------------------------+ Type Data where "x" is the generic command, a single letter. The letter S is not yet in use, so let's define S to mean SET. The S is followed by a single operand, which includes a single-character length field, similar to other generic command packets. The parameters which may be SET remotely are the ones having to do with file transfer and Kermit protocol in general, not system-dependent or communications-dependent parameters, since these must already have been set prior to making the initial connection, and must be set correctly in any event BEFORE you can successfully send a REMOTE SET (or any other) packet to the server. The most needed REMOTE SET command is REMOTE SET FILE TYPE {TEXT,BINARY}, but the others should be specified in the protocol too. Numeric codes are assigned to the parameters and values, so that the mechanism for conveying this information is system- and language-independent and reasonably compact. The REMOTE SET command does exactly what the corresponding SET command would do if it had been given to the remote server as an interactive command before it entered server mode. Command Code Values REMOTE SET ATTRIBUTES IN ALL 132 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN LENGTH 133 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN TYPE 134 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN DATE 135 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN CREATOR 136 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN ACCOUNT 137 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN AREA 138 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN BLOCK-SIZE 139 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN ACCESS 140 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN ENCODING 141 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN DISPOSITION 142 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN PROTECTION 143 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN GPROTECTION 144 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN SYSTEM-ID 145 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN FORMAT 146 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN SYS-INFO 147 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN BYTE-COUNT 148 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT ALL 232 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT LENGTH 233 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT TYPE 234 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT DATE 235 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT CREATOR 236 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT ACCOUNT 237 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT AREA 238 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT BLOCK-SIZE 239 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT ACCESS 240 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT ENCODING 241 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT DISPOSITION 242 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT PROTECTION 243 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT GPROTECTION 244 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT SYSTEM-ID 245 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT FORMAT 246 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT SYS-INFO 247 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT BYTE-COUNT 248 0 = OFF, 1 = ON REMOTE SET FILE TYPE 300 0 = TEXT, 1 = BINARY REMOTE SET FILE NAMES 301 0 = CONVERTED, 1 = LITERAL REMOTE SET FILE COLLISION 302 0 = RENAME, 1 = REPLACE, 2 = BACKUP, 3 = APPEND, 4 = DISCARD, 4 = ASK REMOTE SET FILE REPLACE 303 0 = PRESERVE, 1 = DEFAULT REMOTE SET FILE INCOMPLETE 310 0 = DISCARD, 1 = KEEP REMOTE SET INCOMPLETE (same as above) REMOTE SET BLOCK-CHECK 400 number (1, 2, or 3) REMOTE SET RECEIVE PACKET-LENGTH 401 number (10-9024) REMOTE SET RECEIVE TIMEOUT 402 number (any, 0 = no timeout) REMOTE SET RETRY 403 number (any, 0 = no limit) REMOTE SET SERVER TIMEOUT 404 number (any, 0 = no timeout) REMOTE SET TRANSFER CHARACTER-SET 405 Character Set Designator REMOTE SET WINDOW-SLOTS 406 number (1-31) One Kermit program should not have knowledge of another Kermit program's local character sets, therefore REMOTE SET FILE CHARACTER-SET is not included. The Transfer Character Set Designator is the one described in the "ISO/Kermit" proposal. For example "I2/100" (ISO Latin Alphabet 1), "I2/144" (ISO Latin/Cyrillic), or "I14/13" (Japanese Roman/Katakana). The command would use the name (for example REMOTE SET TRANSFER CHARACTER-SET LATIN1) and the generic server command packet would use the corresponding designator. REMOTE SET LANGUAGE is omitted for the present, but can be added later. The problem here is assigning a unique code to each of the world's languages. The numbers shown for the codes and values are expressed as character strings composed of ASCII digits, 0-9. Here are examples, showing the TYPE and DATA fields of the Kermit packet: GS#101!0 = REMOTE SET ATTRIBUTE LENGTH OFF GS#202!0 = REMOTE SET ATTRIBUTE TYPE OFF GS#300!1 = REMOTE SET FILE TYPE BINARY GS#400!2 = REMOTE SET BLOCK CHECK 2 GS#401$1000 = REMOTE SET RECEIVE PACKET-LENGTH 1000 GS#405&I2/100 = REMOTE SET TRANSFER CHARACTER-SET LATIN-1 ORGANIZATION AND EXPANSION: The codes are numeric strings, with the hundred's place assigned roughly according to "topic": 100's for Incoming Attributes, 200's for Outbound Attributes, 300's for file-related items, and 400's for packet-related items. Note that the SET ATTRIBUTE codes are equal to 100 or 200 plus the value of the corresponding attribute designator. There is plenty of room for expansion within each category, and new categories can be added as required. PROTOCOL: The person using the client Kermit program issues a REMOTE SET command for a single parameter, such as REMOTE SET FILE TYPE BINARY. The program forms the corresponding G packet and sends it to the server. The server program can respond in any of the following ways, and the client program should be prepared for each kind of response: E-packet: An Error packet. The server does not understand REMOTE SET packets, or it is not able to perform the specific SET that was requested. Therefore the client must not assume that the SET has been done, and if it is in local mode, it must give a message to the user, as described below. Y-packet: An Acknowledgement. The server accepted the command, and performed the requested SET. The data field of the Y-packet can be empty, to indicate that the requested value was accepted. Or it can contain the value which the server actually set. For example, the user types REMOTE SET RECEIVE PACKET-LENGTH 5000 but the server only supports lengths up to 1000: To server --> GS#400$5000 Y1000 <-- To client CLIENT IMPLEMENTATION: A client can include support for any number of the REMOTE SET commands, or none at all. A minimal implementation might include only REMOTE SET FILE TYPE. This would include addition of the command to the program's command tables, code to send the generic packet, and code to interpret the response and issue any appropriate messages to the user, like the contents of the error packet data field, or any altered value that the server sent back in the data field of an acknowledgement. Examples: REMOTE SET command succeeded REMOTE SET value changed to 1000 REMOTE SET command failed: <reason from data field of E-packet> SERVER IMPLEMENTATION: A server can also include support for any number of the REMOTE SET commands, or none at all. If it supports none at all, then it will automatically respond to a REMOTE SET packet with an error packet containing a message like "Unimplemented REMOTE command". If the server receives a REMOTE SET packet for a parameter it does not support the REMOTE SETting of, then it should respond with an error packet containing the message "Unknown REMOTE SET parameter". If the server gets a REMOTE SET packet for a parameter which is known to it, then it should: (a) Set the parameter to the requested value and respond with an empty Y packet, or: (b) If the requested value exceeds the server's maximum value for the parameter, set it to its own maximum value and respond with a Y packet containing the new value in its data field, as in the packet-length example above. If the server is a "permanent" Kermit server which cannot be terminated using BYE or FINISH, then when the user disengages from it using BYE, FINISH, or LOGOUT, then when the server receives a BYE, FINISH, or LOGOUT command, it should revert any parameters that were changed by REMOTE SET back to the values that were in use when server mode was entered. Thanks to Joe Doupnik and John Chandler for their assistance in the design of this protocol extension. ------------------------------ End of Info-Kermit Digest *************************